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Abstract Control code is a concept that is closely related to a frequently occur- 
ring practitioner's view on what is a program: code that is capable of controlling 
the behaviour of some machine. We present a logical approach to explain issues 
concerning control codes that are independent of the details of the behaviours that 
are controlled. Using this approach, such issues can be explained at a very abstract 
level. We illustrate this among other things by means of an example about the pro- 
duction of a new compiler from an existing one. The approach is based on abstract 
machine models, called machine structures. We introduce a model of systems that 
provide execution environments for the executable codes of machine structures 
and use it to go into portability of control codes. 
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1 Introduction 

In theoretical computer science, the meaning of programs usually plays a promi- 
nent part in the explanation of many issues concerning programs. Moreover, what 
is taken for the meaning of programs is mathematical by nature. On the other hand, 
it is customary that practitioners do not fall back on the mathematical meaning of 
programs in case explanation of issues concerning programs is needed. More often 
than not, they phrase their explanations from the viewpoint that a program is code 
that is capable of controlling the behaviour of some machine. Both theorists and 
practitioners tend to ignore the existence of this contrast. In order to break through 
this, we as theorists make in this paper an attempt to map out the way in which 
practitioners explain issues concerning programs. 
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We informally define control code as code that is capable of controlling the 
behaviour of some machine. There are control codes that fail to qualify as pro- 
grams according to any conceivable theory of programming. For that reason, we 
make the distinction between control codes and programs. However, there are is- 
sues concerning programs that can be explained at the level of control codes by 
considering them as control codes that qualify as programs. Relative to a fixed 
machine, the machine-dependent concept of control code that qualifies as program 
is more abstract than the machine-independent concept of program: control code 
that qualifies as program is just representative (on the fixed machine) of behaviour 
associated with a program with which it is possible to explain the behaviour This 
might be an important motive to explain issues concerning programs at the level 
of control codes. 

To simplify matters, we consider in this paper non-interactive behaviour only. 
We consider this simplification desirable to start with. Henceforth, control codes 
are implicitly assumed to control non-interactive behaviour only and the be- 
haviours associated with programs are implicitly assumed to be non-interactive. 

Our attempt to map out the way in which practitioners explain issues concern- 
ing programs yields a logical approach to explain issues concerning control codes 
that are independent of the details of the behaviours that are controlled. Machine 
structures are used as a basis of the approach. They are inspired by the machine 
functions introduced in |13 | to provide a mathematical basis for the T-diagrams 
proposed in 1.1 U . A machine structure offers a machine model at a very abstract 
level. 

We illustrate the approach by means of some examples. The issues explained 
in the examples are well understood for quite a time. They are primarily meant to 
demonstrate the effectiveness of the approach. In the explanations given, we have 
consciously been guided by empirical viewpoints usually taken by practitioners 
rather than theoretical viewpoints. Those empirical viewpoints may be outside the 
perspective of some theorists. 

Mapping out the way in which practitioners explain issues concerning pro- 
grams, phrased as a matter of applied mathematics, seems to lead unavoidably to 
unexpected concepts and definitions. This means among other things that steps 
made in this paper cannot always be motivated directly from the practice that we 
map out. This is an instance of a general property of applied mathematics that we 
have to face: the design of a mathematical theory does not follow imperatively 
from the problems of the application area concerned. 

We believe that the presented approach is useful because in various areas fre- 
quently no distinction is made between programs and control codes and interest is 
primarily in issues concerning control codes that are independent of the details of 
the behaviours that are controlled. Some examples of such areas are software asset 
sourcing and software patentsQ Moreover, we find that control code production is 
in the end what software construction is about. 



' Software asset sourcing is an important part of IT sourcing, see e.g. |20||24lfT2l . An 
extensive study of software patents and their implications on software engineering practices 
can be found in |,5J. 
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Machine structures in themselves are not always sufficient to explain issues 
concerning control codes that are independent of the details of the behaviours that 
are controlled. If systems that provide execution environments for the executable 
codes of machine structures are involved, then more is needed. We introduce an 
execution architecture for machine structures as a model of such systems and ex- 
plain portability of control codes using this execution architecture. An extension 
of basic thread algebra, introduced in |6| under the name basic polarized process 
algebra, is used to describe processes that operate upon the execution architecture. 
The reason to use basic thread algebra is that it has been designed as an algebra 
of processes that interact with machines of the kind to which also the execution 
architecture belongs. It is quite awkward to describe processes of that kind using a 
general process algebra such as ACP 1 14], CCS |21 1 or CSP IfTTl . 

This paper is organized as follows. First, we introduce machine structures (Sec- 
tion |2|i. Next, we introduce control code notations and program notations (Sec- 
tion|3]l. Then, we present our approach to explain issues concerning control codes 
by means of examples about the production of a new assembler using an existing 
one and the production of a new compiler using an existing one (Section |4]i. We 
also use this approach to explain the relation between compilers and interpreters 
(Section |5]l. Following this, we sum up the effects of withdrawing a simplifying 
assumption concerning the representation of control codes made in the foregoing 
(Section|6]l. After that, we outline an execution architecture for machine structures 
(Section|7]i. Then, we review the extension of basic thread algebra that covers the 
effects of applying threads to services (Section |8]l. Following this, we formalize 
the execution architecture for machine structures and define the family of services 
determined by it (Section |9]l. After that, we explain portability of control codes 
using thread algebra and the execution architecture services (SectionfTOli. Finally, 
we make some concluding remarks (SectionfTTTi. 

Up to Section]?] this paper is a major revision of |l3]. It has been substantially 
rewritten so as to streamline the material. Several important technical aspects have 
been significantly modified. 



2 Machine Functions and Machine Structures 

In this section, machine structures are introduced. Machine structures are the basis 
for our approach to explain issues concerning control codes. They are very abstract 
machine models and cover non-interactive machine behaviour only. 

First, we introduce the notion of machine function introduced in [l3|. It general- 
izes the notion of machine function introduced in 1 13] by covering machines with 
several outputs. Machine functions are very abstract machine models as well, but 
they are less suited than machine structures to model general purpose machines 
such as computers. Machine structures can easily be defined without reference to 
machine functions. The introduction of machine functions is mainly for expository 
reasons. 
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2.1 Machine Functions 

A machine function /i is actually a family of functions: it consists of a function 
Hn for each natural number n > 0. Those functions map each finite sequence of 
bit sequences to either a bit sequence or M or D. Here, M stands for meaningless 
and D stands for divergent. A machine function is supposed to model a machine 
that takes several bit sequences as its inputs and produces several bit sequences as 
its outputs unless it does not halt on the inputs. Let xi, . . . , a;,„ be bit sequences. 
Then the connection between the machine function /i and the machine modelled 
by it can be understood as follows^ 

- if jin{{xi, ■ ■ ■ , Xyn)) is a bit sequence, then the machine function ji models a 
machine that produces fin{{xi, . . . , Xm)) as its nth output on it taking xi, . .., 
Xm as its inputs; 

- if iin{{xi, ■ ■ ■ , Xm)) is M, then the machine function fi models a machine that 
produces less than n outputs on it taking xi, . . . , Xm as its inputs; 

- if fin{{xi, . . . , Xjn)) is D, then the machine function fi models a machine that 
does not produce any output on it taking xi, . . . , Xm as its inputs because it 
does not halt on the inputs. 

Concerning the machine modelled by a machine function, we assume the follow- 
ing: 

- if it does not halt, then no output gets produced; 

- if it does halt, then only finitely many outputs are produced; 

- if it does not halt, then this cannot be prevented by providing more inputs; 

- if it does halt, then the number of outputs cannot be increased by providing 
less inputs. 

The intuitions behind the first two assumptions are obvious. The intuition behind 
the third assumption is that, with respect to not halting, a machine does not use 
more inputs than it needs. The intuition behind the last assumption is that, with 
respect to producing outputs, a machine does not use more inputs than it needs. 

Henceforth, we write BS for the set {0, 1}* of bit sequences. It is assumed that 
M ^ and D ^ SS. 

We now define machine functions in a mathematically precise way. 

Let BS C BS. Then a machine function /i on BS is a family of functions 

{fin ■■ BS* {BS U {D, M}) I n G N} 



^ We write ( ) for the empty sequence, (x) for the sequence having x as sole element, 
and X x' for the concatenation of finite sequences x ™d x' ■ We use {xi, . . . , Xn) as 
a shorthand for (xi) ^ . . . ^ {x„). We write X* for the set of all finite sequences with 
elements from set X. 
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satisfying the following rules: 

A„GN(ArneN(M«(x) = D ^ /i„(x) = D)) , 
A„gn(a^"(x) 7^ D ^ (Vm6N,m>nMm(x) = M)) , 
AneN(A„^eN,m>n(M"(x) = M ^ /X„(x) = M)) , 

A„eN(Mn(x) = D ^ /x„(x^x') = D) , 
A„eN(/«"(x^x') = M ^ Mn(x) = M) . 
We write AlF for the set of all machine functions. 

Example 1 Take a high-level programming language PL and an assembly lan- 
guage AL. Consider a machine function c/, which models a machine dedicated 
to compiling PL programs, and a machine function df , which models a machine 
dedicated to disassembling executable codes. Suppose that the compihng machine 
takes a bit sequence representing a PL program as its only input and produces a 
bit sequence representing an AL version of the PL program as its first output, a 
bit sequence representing a hsting of error messages as its second output, and an 
executable code for the PL program as its third output. Moreover, suppose that the 
disassembling machine takes an executable code as its only input and producing a 
bit sequence representing an AL version of the executable code as its first output 
and a bit sequence representing a hsting of error messages as its second output. 
The relevant properties of the machines modelled by cf and df that may now be 
formulated include: 

df^m^i) ^ df,{{x))^{), 

c/2((^)) = () ^ df,icf,{{x))) = cfMx)). 

These formulas express that executable code is produced by the compiling ma- 
chine unless errors are found, disassembly succeeds unless errors are found, and 
disassembly is the inverse of assembly. 

Machines such as the compiling machine and the disassembling machine are 
special purpose machines. They are restricted to exhibit a particular type of be- 
haviour. Computers are general purpose machines that can exhibit different types 
of behaviour at different times. This is possible because computers are code con- 
trolled machines. A code controlled machine takes one special input that controls 
its behaviour. In general, not all bit sequences that a code controlled machine can 
take as its inputs are capable of controlling the behaviour of that machine. The bit 
sequences that are capable of controlling its behaviour are known as its executable 
codes. Note that executable code is a machine-dependent concept. 

Machine functions can be used to model code controlled machines as well. We 
will use the phrase code controlled machine function for machine functions that 
are used to model a code controlled machine. We will use the convention that the 
first bit sequence in the argument of the functions that make up a code controlled 
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machine function corresponds to the special input that controls the behaviour of the 
machine modelled. Because, in general, not all bit sequences that a code controlled 
machine can take as its inputs are executable codes, more than just a machine 
function is needed to model a code controlled machine. That is why we introduce 
machine structures. 



2.2 Machine Structures 

A machine structure 9Jl consists a set of bit sequences BS, functions that make 
up a machine function on BS, and a subset E of BS. If E is empty, then the 
machine structure 9}t is essentially the same as the machine function contained in 
it. If is not empty, then the machine structure dJt is supposed to model a code 
controlled machine. In the case where E is not empty, the connection between 
the machine structure 9Jt and the code controlled machine modelled by it can be 
understood as follows: 

- BS is the set of all bit sequences that the code controlled machine modelled 
by 9JI can take as its inputs; 

- if X E E, then the bit sequence x belongs to the executable codes of the code 
controlled machine modelled by 9Jt; 

- if a; S E, then the functions /i'^ that are defined by . . . , j/m)) = 
Unii^i Ui, ■ ■ ■ , Vm)) make up a machine function on BS modeling a machine 
that exhibits the same behaviour as the code controlled machine modelled by 
SDT exhibits under control of the executable code x. 

The assumptions made about the machine modelled by a machine structure are the 

same as the assumptions made before about the machine modelled by a machine 
function. It is tempting to add the following assumption: 

- if the special input meant to control its behaviour does not belong to its exe- 
cutable codes, then the machine halts without having produced any output. 

We refrain from adding this assumption because it is to be expected that: (a) we 
can do without it in explaining issues concerning control codes; (b) it does not hold 
good for all machines that we may encounter. Moreover, in case we would incor- 
porate this assumption in the notion of machine structure, it would not supersede 
the notion of machine function. 

We now define machine structures in a mathematically precise way. 

A machine structure 971 is a structure composed of 

- a set BS C BS, 

- a unary function /i„ : BS* — > {BS U {D, M}), for each n e N, 

- a unary relation E C BS, 

where the family of functions {/^„ : BS* {BSV{D, M}) | n G N} is a machine 
function on BS. We say that 9JI is a code controlled machine structure if E ^ $, 
and we say that f!Jl is a dedicated machine structure if E = 
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Let VJl — {BS, {fin I n e N}, E) be a code controlled machine structure, and 
let X G E. Then the meaning of x with respect to 9Jl, written |a;|^, is the machine 
function 

: BS* {BS U {D, M}) 1 7i e N} , 
where the functions ^'^ are defined by 

Ain((yi: ■ ■ • :2/m)) = ( (a;, 2/1 , • • • , ^m) ) ■ 

Moreover, let a;', G -E. Then x' is behaviourally equivalent to x" on OJl, written 

x' =^h^"'if I^T = k'T- 

Let 2Jl = (S<5, {/in 1 n £ N}, iS) be a code controlled machine structure. 
Then we will write 

a; yi' • • • for M«((a;,?/i, ...,?/,„)) . 
Moreover, we will write 

x»»gj^yi,...,ym for a; ••^ yi, . . . , . 

We will also omit 371 if the machine structure is clear from the context. 

Example 2 Take a code controlled machine structure 9Jl = {BS, {/i„ | n G 
N}, iS). Consider again the machine functions c/ and df from Example [T] These 
machine functions model a machine dedicated to compiling programs in some 
high-level programming language PL and a machine dedicated to disassembling 
executable codes, respectively. Let Cc/, Cdf G -E be such that 

|e,/r = c/ and Icd/T = d/ . 

Then ecf and e^/ are executable codes that control the behaviour of the code con- 
trolled machine modelled by 971 such that this machine behaves the same as the 
dedicated machine modelled by cf and the dedicated machine modelled by df, 
respectively. This implies that for all x G BS and n G N: 

ec/ ••ot a; = c/„((x)) and e^/ ..g^ x = rf/„((x)) . 

Note that for cf there may be an e'^y G E with e'^y c-cf such that |e'^y |™ — cf, 
and likewise for df. 

A code controlled machine structure Tl = {BS, {fin \ n G N}, E) determines 
all by itself a machine model. For an execution, which takes a single step, an ex- 
ecutable code X € E, a sequence {yi, . . . , j/,„) G BS* of inputs and the machine 
function {/i„ | n G N} are needed. The executable code is not integrated in the 
machine in any way. In particular, it is not stored in the machine. As nothing is 
known about any storage mechanism involved, due to the abstract nature of ma- 
chine structures, it is not plausible to classify the model as a stored code machine 
model. 
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2.3 Identifying the Input that Controls Machine Behaviour 

It is a matter of convention that the first bit sequence in the argument of the func- 
tions that make up the machine function of a code controlled machine structure 
corresponds to the special input that controls the behaviour of the machine mod- 
elled. The issue is whether a justification for this correspondence can be found in 
properties of the code controlled machine structure. This amounts to identifying 
the input that controls the behaviour of the machine modelled. 

Take the simple case where always two inputs are needed to produce any output 
and always one output is produced. Then a justification for the correspondence 
mentioned above can be found only if the machine function involved is asymmetric 
and moreover the first bit sequence in the argument of the function that yields the 
first output overrules the second bit sequence. Here, by overruling is meant being 
more in control. 

In this simple case, the criteria of asymmetry and overruling can easily be made 
more precise. Suppose that 371 ~ {BS,{iin \ n e N},i?) is a code controlled 
machine structure that models a machine that needs always two inputs to produce 
any output and produces always one output. Then the machine function {fin \ n e 
N} is asymmetric if there exist x,y E BS such that iii{x, y) ^ l^iiy, x). The first 
bit sequence in the argument of the function /ii overrules the second one if there 
exist xi,X2 € E and zi,Z2 G BS with zi ^ Z2 such that fj,i{xi,y) — zi and 
Ml (^2 1 y) — Z2 for all y G BS. It is easily proved that the first bit sequence in 
the argument of the function /ii overrules the second one only if the second bit 
sequence in the argument of the function /ii does not overrule the first one. 

The criterion of overruling becomes more interesting if more than two inputs 
may be needed to produce any output, because this is usually the case with general- 
purpose machines. For example, on a general-purpose machine, the first input may 
be an executable code for an interpreter of intermediate codes produced by a com- 
piler for some high-level programming language PL, the second input may be a bit 
sequence representing the intermediate code for a PL program, and one or more 
subsequent inputs may be bit sequences representing data needed by that program. 
In this example, the first input overrules the second input and subsequent inputs 
present and in addition the second input overrules the third input and subsequent 
inputs present. 

3 Control Code Notations and Program Notations 

In this section, we introduce the concepts of control code notation and program 
notation in the setting of machine structures and discuss the differences between 
these two concepts. The underlying idea is that a control code is a code that is 
capable of controlling the behaviour of some machine and a program is a control 
code that is acquired by programming. The point is that there exist control codes 
that are not acquired by programming. In ifTSl . which appeared after the report 
version of the current paper |f8l|, a conceptual distinction is made between proper 
programs and dark programs. We found that proper programs correspond with 
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control codes that are acquired by programming and dark programs correspond 
with control codes that are not acquired by programming. As a matter of fact, the 
notion of machine structure allows for the discussion of proper and dark programs 
in ifTSll to be made more precise. 

3.1 Control Code Notations 

The intuition is that, for a fixed code controlled machine, control codes are objects 
(usually texts) representing executable codes of that code controlled machine. The 
principal examples of control codes are the executable codes themselves. Note 
that, like the concept of executable code, the concept of control code is machine- 
dependent. A control code notation for a fixed code controlled machine is a collec- 
tion of objects together with a function which maps each of the objects from that 
collection to a particular executable code of the code controlled machine. 

In order to make a code controlled machine transform members of one control 
code notation into members of another control code notation, like in compiling and 
assembling, control codes that are not bit sequences must be represented by bit se- 
quences. To simplify matters, we will assume that all control code notations are 
collections of bit sequences. Assuming this amounts to identifying control codes 
with the bit sequences representing them. In Section |6] we will withdraw this as- 
sumption. 

Let 9Jl = {BS, {fin I £ N}, E) be a code controlled machine structure. 
Then a control code notation for 9Jl consists of a set CCN C BS and a function 
ip-.CCN E. The members of CCN are called control codes for 971. The function 
ij) is called a machine structure projection. 

Let ( CCN, ip) be a control code notation for a code controlled machine struc- 
ture {BS, {^n \n eN},E). Then we assume that ijj{c) = c for all c S CCN n E. 

Let 971 be a code controlled machine structure, let ( CCN, ip) be a control code 
notation for 971, and let c e CCN. Then the meaning of c with respect to 971, 
written |c|pf;^, is \ip{c)\^. 

Control codes, like executable codes, are given a meaning related to one code 
controlled machine structure. The executable codes of a code controlled machine 
structure themselves make up a control code notation for that machine structure. 
Let 971 — {BS, | n £ N}, E) be a code controlled machine structure, and let 
1e be the identity function on E. Then {E, 1^;) is a control code notation for 971. 
We trivially have \e\™ — |e|^ for all e € E. Henceforth, we loosely write E for 
the control code notation {E, 1e). 

3.2 Program Notations 

To investigate the conditions under which it is appropriate to say that a control code 
notation qualifies as a program notation, it is in fact immaterial how the concept of 
program is defined. However, it is at least convenient to make the assumption that, 
whatever the program notation, there is a hypothetical machine model by means 
of which the intended behaviour of programs from the program notation can be 
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explained at a level that is suited to our purpose. We believe that this assumption 
is realistic. 

Let some theory of programming be given that offers a reliable definition of 
the concept of program. Then an acknowledged program notation is a set PGN 
of programs. It is assumed that there is a well-understood hypothetical machine 
model by means of which the intended behaviour of programs from PGN can 
be explained at a level that allows for the input-output relation of programs from 
PGN, i.e. the kind of behaviour modelled by machine functions, to be derived. It is 
also assumed that this hypothetical machine model determines a function |- |pgw : 
PGN MJ- which maps programs to the machine functions modelling their 
behaviour at the abstraction level of input-output relations. 

In [61, a theory, called program algebra, is introduced in which a program is 
a finite or infinite sequence of instructions. Moreover, the intended behaviour of 
instruction sequences is explained at the level of input-output relations by means 
of a hypothetical machine model which involves processing of one instruction at 
a time, where some machine changes its state and produces a reply in case the in- 
struction is not a jump instruction. This hypothetical machine model is an analytic 
execution architecture in the sense of [10] . In the current paper, the definition of 
the concept of program from ||6| could be used. However, we have not fixed a par- 
ticular concept of program because we intend to abstract from the details involved 
in any such conceptual definition. 

Note that programs, unlike control codes, are given a meaning using a hypo- 
thetical machine model. This means that the given meaning is not related to some 
code controlled machine structure. 

3.3 Control Code Notations Qualifying as Program Notations 

The intuition is that a control code notation for a code controlled machine qualifies 
as a program notation if there exist an acknowledged program notation and a func- 
tion from the control code notation to the program notation that maps each control 
code to a program such that, at the level of input-output relations, the machine 
behaviour under control of the control code coincides with the behaviour that is 
associated with the corresponding program. If a control code notation qualifies as 
a program notation, then its elements are considered programs. 

Let QJt be a code controlled machine structure, and let {GCN, -ip) be a control 
code notation for 9Jl. Then {GCN, tp) qualifies as a program notation if there exist 
an acknowledged program notation PGN and a function (p : GCN PGN such 
that for all c e GCN: 

\^ic)r = \HC)\PGN ■ 

This definition implies that, in the case of a control code notation that qualifies 
as a program notation, control codes can be given a meaning using a hypothetical 
machine model. Control code by itself is just representative of machine behaviour 
without any indication that it originates from a program with which it is possi- 
ble to explain the behaviour by means of a well-understood hypothetical machine 
model. The function cp whose existence is demanded in the definition is suggestive 
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of reverse engineering: by its existence, control codes look to be implementations 
of programs on a code controlled machine. We might say that the reason for clas- 
sifying a control code notation in the ones that qualify as a program notation lies 
in the possibility of reverse engineering. The function is the opposite of a repre- 
sentation. It might be called a co-representation. 

Suppose that 9JI = (55", {/u„ | n G N},-E) is a code controlled machine 
structure and {E, 1e) qualifies as a program notation. Then 9Jl models a code 
controlled machine whose executable codes constitute a control code notation that 
qualifies as a program notation. Therefore, it is appropriate to call Tl a program 
controlled machine structure. A program controlled machine structure is a code 
controlled machine structure, but there is additional information which is consid- 
ered to make it more easily understood from the tradition of computer program- 
ming: each executable code can be taken for a program and the intended behaviour 
of that program can be explained by means of a well-understood hypothetical ma- 
chine model. It is plausible that, for any code controlled machine structure model- 
ing a real machine, there is additional information which is considered to make it 
more easily understood from some tradition or another. 

We take the view that a code controlled machine structure having both exe- 
cutable codes that can be considered programs and executable codes that cannot 
be considered programs are improper. Therefore, we introduce the notion of proper 
code controlled machine structure. 

Let Tl = {BS, {Hn I n e N}, E) be a code controlled machine structure. 
Then 9Jl is a proper code controlled machine structure if {E' , 1^') qualifies as a 
program notation for some E' C E only if {E, 1 e) qualifies as a program notation. 

3.4 Control Code Notations Not Qualifying as Program Notations 

The question arises whether all control code notations qualify as program nota- 
tions. If that were true, then the conceptual distinction between control code no- 
tations and program notations is small. If a control code notation qualifies as a 
program notation, then all control codes concerned can be considered the result of 
implementing a program on a code controlled machine. This indicates that coun- 
terexamples to the hypothesis that all control code notations qualify as program 
notations will concern control codes that do not originate from programming. We 
give two counterexamples where control codes arise from artificial intelligence. 

Consider a neural network in hardware form, which is able to learn while work- 
ing on a problem and thereby defining parameter values for many firing thresholds 
for artificial neurons. The parameter values for a particular problem may serve as 
input for a machine that needs to address that problem. These problem dependent 
parameter inputs can be considered control codes by all means. However, there is 
no conceivable theory of programming according to which these problem depen- 
dent parameter inputs can be considered programs. The feature of neural networks 
that is important here is their ability to acquire control code by another process 
than programming. 

Consider a purely hardware made robot that processes geographical data 
loaded into it to find a target location. The loaded geographical data constitute the 
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only software that determines the behaviour of the robot. Therefore, the loaded ge- 
ographical data constitute control code. However, there is no conceivable theory of 
programming according to which such control codes can be considered programs. 
They are certainly acquired by another process than programming. 

In the case of control code notations that qualify as program notations, the 
control codes are usually produced by programming followed by compiling or 
assembling. The examples illustrate different forms of control code production 
that involve neither programming nor compiling or assembling. The first example 
shows that control codes can be produced without programming by means of arti- 
ficial intelligence based techniques. The second example shows that the behaviour 
of machines applying artificial intelligence based techniques can be controlled by 
control codes that are produced without programming. 

4 Assemblers and Compilers 

In the production of control code, practitioners often distinguish two kinds of con- 
trol codes in addition to executable codes: assembly codes and source codes. An 
assembler is a control code corresponding to an executable code of a code con- 
trolled machine that controls the behaviour of that code controlled machine such 
that it transforms assembly codes into executable codes and a compiler is a con- 
trol code corresponding to an executable code of a code controlled machine that 
controls the behaviour of that code controlled machine such that it that transforms 
source codes into assembly codes or executable codes. 

In this section, we consider the issue of producing a new assembler for some 
assembly code notation using an existing one and the similar issue of producing 
a new compiler for some source code notation using an existing one. Whether an 
assembly code notation or a source code notation quahfies as a program notation 
is not relevant to these issues. 

4.1 Assembly Code Notations and Source Code Notations 

At the level of control codes for machine structures, the control code notations 
that are to be considered assembly code notations and the control code notations 
that are to be considered source code notations cannot be characterized. The level 
is too abstract. It happens to be sufficient for many issues concerning assemblers 
and compilers, including the ones considered in this section, to simply assume that 
some collection of control code notations comprises the assembly code notations 
and some other collection of control code notations comprises the source code 
notations. 

Henceforth, we assume that, for each machine structure SOT, disjoint sets 
MJ^^m and SCMmi of control code notations for 9Jl have been given. The members 
of MJ^m and SCMm are called assembly code notations for 9Jl and source code 
notations for OT, respectively. 

The following gives an idea of the grounds on which control code notations 
are classified as assembly code notation or source code notation. Assembly code 
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is control code that is very close to executable code. This means that there is a 
direct translation of assembly codes into executable codes. An assembly code no- 
tation is specific to a machine. Source code is control code that is not very close 
to executable code. The translation of source code into executable code is more 
involved than the translation of assembly code into executable code. Usually, a 
source code notation is not specific to a machine. 

A high-level programming language, such as Java |15 | or C# |16|, is consid- 
ered a source code notation. The term high-level programming language suggests 
that it concerns a notation that qualifies as a program notation. However, as men- 
tioned above, whether a source code notation qualifies as a program notation is not 
relevant to the issues considered in this section. 

4.2 Control Code Notations Involved in Assemblers and Compilers 

Three control code notations are involved in an assembler or compiler: it lets a code 
controlled machine transform members of one control code notation into members 
of another control code notation and it is itself a member of some control code 
notation. We introduce a special notation to describe this aspect of assemblers and 
compilers succinctly. 

Let 9Jl — {BS, {/i„ I n £ N}, E) be a code controlled machine structure, 
and let {CCN, V), (CCN', V') and {CCN", il^") be control code notations for 971. 
Then we write cc [CCN' -> CCN"] : CCN for 

cc e CCN A Vcc' e CCN' . (3cc" e CCN" . V'(cc) ••^ cc' = cc") . 

We say that cc is in executable form if CCN C E, that cc is in assembly form if 
CCN e Mhfm, and that cc is in source form if CCN e SChfm- 

4.3 The Assembler Fixed Point 

In this subsection, we consider the issue of producing a new assembler for some 
assembly code notation using an existing one. 

Let 971 = [BS, | n G N}, E) be a code controlled machine structure, and 
let {ACN, tp) be a control code notation for 971 that belongs to AOVm- Suppose 
that ass [A CN E] : iJ is an existing assembler for A CN. This assembler is in 
executable form. Suppose further that a new assembler ass' [A CN ^E]:A CN for 
A CN is made available. This new assembler is not in executable form. It needs to 
be assembled by means of the existing assembler The new assembler is considered 
correct if behaviouraUy equivalent executable codes are produced by the existing 
assembler and the one obtained by assembling the new assembler by means of the 
existing assembler, i.e. 

Vac G ACN • ass •• ac {ass •• ass') •• ac . (1) 

Let ass" be the new assembler in executable form obtained by assembling ass' 
by means of ass, i.e. ass" = ass •• ass'. Now, ass' could be assembled by means 
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of ass" instead of ass. In case ass" produces more compact executable codes than 
ass, this would result in a new assembler in executable form that is more compact. 
Let ass"' be the new assembler in executable form obtained by assembling ass' 
by means of ass", i.e. ass'" — ass" •• ass' — {ass •• ass') •• ass'. If ass' is 
correct, then ass" and ass'" produce the same executable codes. That is, 

ass =1^1^ ass . (2) 

This is easy to see: rewriting in terms of ass and ass' yields 

ass •• ass' {ass •• ass') •• ass' , (3) 

which follows immediately from ([T]i. 

Now, ass' could be assembled by means of ass'" instead of ass". However, if 
ass' is correct, this would result in ass'" again. That is, 

ass'" = ass'" •• ass' . (4) 

This is easy to see as well: rewriting the left-hand side in terms of ass' and ass" 
yields 

ass" •• ass' = ass'" •• ass' , (5) 

which follows immediately from (|2]i. The phenomenon expresses by equation (|4]l 
is called the assembler fixed point. 

In theoretical computer science, correctness of a program is taken to mean that 
the program satisfies a mathematically precise specification of it. For the assem- 
bler ass', \/ac e ACN > ip{ass') •• ac — %lj{ac) would be an obvious math- 
ematically precise specification. More often than not, practitioners have a more 
empirical view on the correctness of a program that is a new program serving as a 
replacement for an old one on a specific machine: correctness of the new program 
is taken to mean that the old program and the new program give rise to the same 
behaviour on that machine. The correctness criterion for new assemblers given 
above, as well as the correctness criterion for new compilers given below, is based 
on this empirical view. 



4.4 The Compiler Fixed Point 

In this subsection, we consider the issue of producing a new compiler for some 
source code notation using an existing one. Compilers may produce assembly 
code, executable code or both. We deal with the case where compilers produce 
assembly code only. The reason for this choice will be explained at the end this 
subsection. 

Let 9Jl = {BS , {iin I n £ N}, E) be a code controlled machine structure, 
let {SCN,ips) be a control code notation for 971 that belongs to SCAffjyi, and let 
{ACN, ipi,) be a control code notation for 971 that belongs to J\C\fm- Suppose that 
com [SCN^ACN]:ACN is an existing compilerfor SCN and ass [AGN^E]:E 
is an existing assembler for ACN. The existing compiler is in assembly form. 
However, a compiler in executable form can always be obtained from a compiler 
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in assembly form by means of the existing assembler. Suppose further that a new 
compiler com' [SCN ACN] : SCN for SCN is made available. This new com- 
piler is not in assembly form. It needs to be compiled by means of the existing 
compiler The new compiler is considered correct if 

Vsc e SCN . 

ass •• {{ass •• com) •• sc) (6) 
=^jj ass •• {{ass •• {{ass •• com) •• com')) •• sc) . 

Let com" be the new compiler in assembly form obtained by compiling com' 
by means of com, i.e. com" = {ass •• com) •• com'. Now, com' could be com- 
piled by means of com" instead of com. In case com" produces more compact 
assembly codes than com, this would result in a new compiler in assembly form 
that is more compact. Let com'" be the new compiler in assembly form obtained 
by compiling com' by means of com", i.e. com'" — {ass •• com") •• com' — 
{ass •• {{ass •• com) •• com')) •• com' . If com' is correct, then com" and com'" 
produce the same assembly codes. That is, 

ass •• com" =i^h ass •• com'" . (7) 

This is easy to see: rewriting in terms of ass, com and com' yields 

ass •• {{ass •• com) •• com') 

^beh '^^^ {{o-ss •• {{ass •• com) •• com')) •• com') , 

which follows immediately from (|6|l. 

Now, com' could be compiled by means of com'" instead of com". However, 
if com' is correct, this would result in com'" again. That is, 

com'" ~ {ass •• com'") •• com' . (9) 

This is easy to see as well: rewriting the left-hand side in terms of ass, com' and 
com" yields 

{ass •• com") •• com' — {ass •• com'") •• com' , (10) 

which follows immediately from (|7]i. The phenomenon expresses by equation (|9]l 
is called the compiler fixed point. It is a non-trivial insight among practitioners 
involved in matters such as software configuration and system administration. 

The explanation of the compiler fixed point proceeds similar to the explana- 
tion of the assembler fixed point in Section 14.31 but it is more complicated. The 
complication vanishes if compilers that produce executable code are considered. 
In that case, due to the very abstract level at which the issues are considered, the 
explanation of the compiler fixed point is essentially the same as the explanation 
of the assembler fixed point. 
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5 Intermediate Code Notations and Interpreters 

Sometimes, practitioners distinguish additional kinds of control codes. Intermedi- 
ate code is a frequently used generic name for those additional kinds of control 
codes. Source code is often implemented by producing executable code for some 
code controlled machine by means of a compiler or a compiler and an assembler 
Sometimes, source code is implemented by means of a compiler and an inter- 
preter. In that case, the compiler used produces intermediate code. The interpreter 
is a control code corresponding to an executable code of a code controlled machine 
that makes that code controlled machine behave as if it is another code controlled 
machine controlled by an intermediate code. 

In this section, we briefly consider the issue of the correctness of such a com- 
bination of a compiler and an interpreter. 

5.7 Intermediate Code Notations 

At the level of control codes for machine structures, like the control code notations 
that are to be considered assembly code notations and the control code notations 
that are to be considered source code notations, the control code notations that are 
to be considered intermediate code notations of some kind cannot be characterized. 
It happens to be sufficient for many issues concerning compilers and interpreters, 
including the one considered in this section, to simply assume that some collection 
of control code notations comprises the intermediate code notations of interest. 

Henceforth, we assume that, for each machine structure 371, a set ICVjui of 
control code notations for 371 has been given. The members of XCVot are called 
intermediate code notations for 37t. 

The following gives an idea of the grounds on which control code notations are 
classified as intermediate code notation. An intermediate code notation is a control 
code notation that resembles an assembly code notation, but it is not specific to any 
machine. Often, it is specific to a source code notation or a family of source code 
notations. 

An intermediate code notation comes into play if source code is implemented 
by means of a compiler and an interpreter However, compilers for intermediate 
code notations are found where interpretation is largely eliminated in favour of 
just-in-time compilation, see e.g. ID, which is material to contemporary program- 
ming languages such as Java and C#. 

In the case where an intermediate code notation is specific to a family of source 
code notations, it is a common intermediate code notation for the source code no- 
tations concerned. The Common Intermediate Language from the .NET Frame- 
work [25 J is an example of a common intermediate code notation. 

5.2 Interpreters 

Interpreters are quite different from assemblers and compilers. An assembler for 
an assembly code notation makes a code controlled machine transform members 
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of the assembly code notation into executable codes and a compiler for a source 
code notation makes a code controlled machine transform members of the source 
code notation into members of an assembly code notation or executable codes, 
whereas an interpreter for an intermediate code notation makes a code controlled 
machine behave as if it is a code controlled machine for which the members of the 
intermediate code notation serve as executable codes. 

We consider the correctness of an interpreter combined with a compiler going 
with it. The correctness criterion given below is in the spirit of the empirical view 
on correctness discussed at the end of Section l43] 

Let VJl = {BS, {fin I n G N}, E) be a code controlled machine structure, let 
{SCN, Tps) be a control code notation for 9Jl that belongs to SCAf^n, let (/CiV, ^pi) 
be a control code notation for 971 that belongs to XCVot, and let {ACN, 4>a.) be a 
control code notation for 971 that belongs to AOVm- Suppose that corria [SCN 
ACN] : ACN is an existing compiler for SCN and ass [ACN E] : E is an 
existing assembler for ACN. The compiler coma lets 971 transform source codes 
into assembly codes. Suppose further that a new compiler conii [SCN ICN] : 
ACN for SCN and a new interpreter int e E for ICN are made available. The 
compiler corrii lets 971 transform source codes into intermediate codes. 

The combination of corrii and int is considered correct if 

Vsc e SCN,{hsi,...,hs„i) e BS* . 
{ass ••ot {{ass ••gjj coma) ••gjj sc)) ••gjj bsi, . . . , 6s,„ (11) 
= int ••(j^ {{ass ••^ comi) ••gjj sc), bsi, . . . , bsm ■ 

While being controlled by an interpreter, the behaviour of a code controlled 
machine can be looked upon as another code controlled machine of which the ex- 
ecutable codes are the intermediate codes involved. The latter machine might ap- 
propriately be called a virtual machine. By means of interpreters, the same virtual 
machine can be obtained on different machines. Thus, all machine-dependencies 
are taken care of by interpreters. A well-known virtual machine is the Java Virtual 
Machine lfT9l . 

6 Bit Sequence Represented Control Code Notations 

In order to make a code controlled machine transform members of one control 
code notation into members of another control code notation, like in assembling 
and compiling, control codes that are not bit sequences must be represented by bit 
sequences. To simplify matters, we assumed up to now that all control code nota- 
tions are collections of bit sequences. In this section, we present the adaptations 
needed in the preceding sections when withdrawing this assumption. It happens 
that the changes are small. 

The Concept of Bit Sequence Represented Control Code Notation 

First of all, we have to generalize the concept of control code notation slightly. 
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Let Tl = {BS, {fin I n G N}, E) be a code controlled machine structure. 
Then a bit sequence represented control code notation for 371 consists of a set 
CCN, a function ^ : CCN —> E, and an injective function p : CCN BS. 
For all c G CCN, p{c) is called the bit sequence representation of c on 271. The 
function p is called the bs-representation function of CCN. 

Let {CCN jtp, p) be a bit sequence represented control code notation for a 
code controlled machine structure {BS, | n S N}, i?). Then we assume that 
ip{c) = c for all c G CCA^ n p(c') = c' for all c' G CCN n 55", and p{c") = c" 
for all c" G CC7V with p(c") G E. The last assumption can be paraphrased as 
follows: if an executable code is the bit sequence representation of some control 
code, then it is its own bit sequence representation. It excludes bs-representation 
functions that inadvertently produce executable codes. 

The Special Notation cc [CCN' ~> CCN"] : CCN 

We have to change the definition of the special notation cc [CCN'^ CCN"] : CCN 
slightly. 

Let 97t = {BS, {/i„ | n G N}, E) be a code controlled machine structure, and 
let {CCN,ij,p), {CCN' , p') and {CCN" ,i>" , p")hQhH sequence represented 
control code notations for 971. Then we write cc [CCN' CCN"] : CCN for 

cc G CCN A Vcc' G CCN' . (3cc" G CCN" . V(cc) ••^ p'{cc') = p"{cc")) . 
The Explanation of the Assembler Fixed Point 

In the explanation of the assembler fixed point given in Section 14.31 we have 
to replace the definitions of ass" and ass'" by ass" ~ ass •• p{ass') and 
ass'" — {ass •• p{ass')) •• p{ass'), assuming that p is the bs-representation func- 
tion of ACN. Moreover, we have to adapt Formulas ([T]i, ([3]l, ©, and (|5]l slightly. 
Formula ([T]l must be replaced by 

Vac G ACN « ass •• p{ac) {ass •• p{ass')) •• p{ac) . 
Formula ([3]i must be replaced by 



ass •• p{ass') 



— bch 



{ass •• p{ass')) •• p{ass') . 



Formula (|4|i must be replaced by 



ass 



= ass' 



III 



p{ass') . 



Formula (|5]l must be replaced by 



ass •• 



p{ass') 



— ass 



III 



p{ass') . 
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The Explanation of the Compiler Fixed Point 

In the explanation of the compiler fixed point given in Section |4!4l we have to re- 
place the definitions of com" and com'" by com" = {ass»» pa{com))»» ps{com') 
and com"' — {ass •• {{ass •• pa{com)) •• ps{com'))) •• ps{com'), assuming that 
Ps is the bs-representation function of SCN and pa is the bs-representation func- 
tion of ACN . Moreover, we have to adapt Formulas dH), (|9|l, and ( fTOl i slightly. 
Formula @ must be replaced by 

Vsc e . 
ass •• ((ass •• pa{com)) •• ps(sc)) 
=bch •• {{o-ss •• ((ass •• pa{com)) •• ps{com'))) •• ps(sc)) . 

Formula (O must be replaced by 

ass •• ((ass •• pa{com)) •• ps{com')) 
—heh •• ((flss •• ((ass •• pa{com)) •• ps{com'))) •• ps{com')) . 

Formula (|9]l must be replaced by 

com"' = (ass •• com'") •• ps{com') . 

Formula ( fTol i must be replaced by 

(ass •• com") •• ps{com') = {ass •• com'") •• ps{com') . 



The Correctness Criterion for Interpreters 

The correctness criterion for interpreters given in Section |S!2l i.e. Formula (fTTT i. 
must be replaced by 

Vsc e 5CiV, (&si,...,&s™) G S5* . 
(ass ••gjj ((ass ••g^ Pa{com^)) ••^ Ps{sc))) ••^jj 6si, . . . , &s™ 
= int ••gjj ((ass ••gr^ pa{com{)) ••gr^ Ps(sc)), fesi, . . . , 6sm , 

assuming that ps is the bs-representation function of SCN and pa is the bs- 
representation function of ACN . 
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7 An Execution Architecture for Macliine Structures 

Machine structures in themselves are not always sufficient to explain issues con- 
cerning control codes that are independent of the details of the behaviours that 
are controlled. In cases where systems that provide execution environments for 
the executable codes of machine structures are involved, such as in the case of 
portability of control codes, an abstract model of such systems is needed. In this 
section, we outline an appropriate model. This model is referred to as the execu- 
tion architecture for code controlled machine structures. It is a synthetic execution 
architecture in the sense of ifTOl . It can be looked upon as an abstract model of 
operating systems restricted to file management facilities and facilities for loading 
and execution of executable codes. 

The execution architecture for code controlled machine structures, which is 
parameterized by a code controlled machine structure 971, is an abstract model 
of a system that provides an execution environment for the executable codes of 
971. It can be looked upon as a machine. This machine is operated by means of 
instructions that either yield a reply or diverge. The possible replies are T and 
F. File names are used in the instructions to refer to the bit sequences present in 
the machine. It is assumed that a countably infinite set JzN'm of file names has 
been given. While designing the instruction set, we focussed on convenience of 
use rather than minimality. 

Let 9Jl = {BS, {^n I n £ N}, E) be a code controlled machine structure. 
Then the instruction set consists of the following instructions: 

- for each / £ JzN'm and hs £ BS, a set instruction set:/: 6s; 

- for each / £ TMm, a remove instruction rm:/; 

- for each /i , /2 £ J-Mm, a copy instruction cp:/i :/2 ; 

- for each /i,/2 £ J-Mm, a move instruction mv:/i:/2; 

- for each /i,/2 £ J-Mm, a concatenation instruction cat:/i:/2; 

- for each /i , /2 £ IJ\fm, a test on equality instruction tsteq :/i :/2 ; 

- for each /i,/2 £ TMrn, a test on difference instruction tstne:/i:/2; 

- for each / £ JiMm, a test on existence instruction tstex:/; 

- for each / £ JHm, a load instruction load:/; 

- for each /i, ... ,/„i, //,... ,/^ £ JHm, an execute instruction 
exec:/i: . . . :/„>//: . . . ://,. 

We write / for this instruction set. 

We say that a file name is in use if it has a bit sequence assigned. A state of 
the machine comprises the file names that are in use, the bit sequences assigned to 
those file names, a flag indicating whether there is a loaded executable code, and 
the loaded executable code if there is one. 

The instructions can be explained in terms of the effect that they have and the 
reply that they yield as follows: 

- set:/: &s: the file name / is added to the file names in use if it is not in use, the 
bit sequence hs is assigned to /, and the reply is T; 

- rm:/: if the file name / is in use, then it is removed from the file names in use 
and the reply is T; otherwise, nothing changes and the reply is F; 
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- cp:/i:/2: if the file name /i is in use, then the file name /2 is added to the file 
names in use if it is not in use, the bit sequence assigned to fi is assigned to /2, 
and the reply is T; otherwise, nothing changes and the reply is F; 

- mv:/i :/2: if the file name /i is in use, then the file name /2 is added to the file 
names in use if it is not in use, the bit sequence assigned to fi is assigned to /2, 
/i is removed from the file names in use, and the reply is T; otherwise, nothing 
changes and the reply is F; 

- cat:/i:/2: if the file names /i and (2 are in use, then the concatenation of the 
bit sequence assigned to /2 and the bit sequence assigned to /i is assigned to /2 
and the reply is T; otherwise, nothing changes and the reply is F; 

- tsteq:/i:/2: if the file names /i and (2 are in use and the bit sequence assigned 
to /i equals the bit sequence assigned to /2, then nothing changes and the reply 
is T; otherwise, nothing changes and the reply is F; 

- tstne:/i:/2: if the file names fi and /2 are in use and the bit sequence assigned 
to /i does not equal the bit sequence assigned to /2, then nothing changes and 
the reply is T; otherwise, nothing changes and the reply is F; 

- tstex:/: if the file name / is in use, then nothing changes and the reply is T; 
otherwise, nothing changes and the reply is F; 

- load:/: if the file name / is in use and the bit sequence assigned to / is a 
member of E, then the bit sequence assigned to / is loaded and the reply is T; 
otherwise, nothing changes and the reply is F; 

- exec:/i: . . . :/m>//: ... :/^: if the file names /i, . . . ,/„ have bit sequences as- 
signed, say bsi, . . . , bs^, and there is a loaded executable code, say x, then: 

- if X ••grjj 6si, . . . , bsjn G BS, then: 

• X ••Iji bsi,. . . , bsm is assigned to // for each i with 1 < i < n such 
that X ••Jjjj &,si, . . . , bs,n e BS, 

• // is removed from the file names in use for each i with 1 < i < n 
such that X ••gjj 651, . . . , bSm = M, 

and the reply is T; 

- if a; ••^ bsi, . . . , bsm = M, then nothing changes and the reply is F; 

- if a; ••^ 6si, . . . , bSm = D, then the machine does not halt; 
otherwise, nothing changes and the reply is F. 



Note that there are three cases in which the instruction exec:/i: ...:/„>/]':... :/^ 
yields the reply F: (a) there is no loaded executable code; (b) there is some file 
name among /i , . . . , that is not in use; (c) there is no output produced, although 
the machine halts. 

The instructions of which the effect depends on the code controlled machine 
structure 931 are the load and execute instructions only. All other instructions could 
be ehminated in favour of executable codes, assigned to known file names. How- 
ever, we believe that elimination of these instructions would not contribute to a 
useful execution architecture. The distinction made between loading and execu- 
tion of executable codes allows for telling load-time errors from run-time errors. 
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8 Thread Algebra 

The execution architecture for code controlled machine structures outlined above 
can be looked upon as a machine which is operated by means of instructions that 
yield T or F as reply. In cases where this execution architecture is needed to explain 
issues concerning control codes, such as in the case of portability of control codes, 
processes that operate upon the execution architecture have to be described. An 
existing extension of BTA (Basic Thread Algebra), first presented in jO), is tailored 
to the description of processes that operate upon machines of the kind to which the 
execution architecture belongs. Therefore, we have chosen to use in SectionfTOlthe 
extension of BTA in question to describe processes that operate upon the execution 
architecture. In this section, we review BTA, including guarded recursion and the 
approximation induction principle, and the relevant extension. 



8.1 Basic Thread Algebra 

BTA is concerned with the behaviours produced by deterministic sequential pro- 
grams under execution. The behaviours concerned are called threads. It does not 
matter how programs are executed: threads may originate from execution by a 
computer, or they may originate from execution by a human operator. In ||6), BTA 
is introduced under the name BPPA (Basic Polarized Process Algebra). 

In BTA, it is assumed that there is a fixed but arbitrary set of basic actions A. 
The intuition is that each basic action performed by a thread is taken as a com- 
mand to be processed by a service provided by the execution environment of the 
thread. The processing of a command may involve a change of state of the service 
concerned. At completion of the processing of the command, the service produces 
a reply value. This reply is either T or F and is returned to the thread concerned. 

Although BTA is one-sorted, we make this sort explicit. The reason for this is 
that we will extend BTA with additional sorts in Section [8^ 

The algebraic theory BTA has one sort: the sort T of threads. BTA has the 
following constants and operators: 

- the deadlock constant D : T; 

- the termination constant S : T; 

- for each a E A, the binary postconditional composition operator _ < a [> _ : 
T X T ^ T. 

Terms of sort T are built as usual. Throughout the paper, we assume that there are 
infinitely many variables of sort T, including u, u, w. 

We use infix notation for postconditional composition. We introduce action 
prefixing as an abbreviation: aop, where p is a term of sort T, abbreviates p< a \>p. 

Let p and q be closed terms of sort T and a E A. Then p<a\>q will perform 
action a, and after that proceed as p if the processing of a leads to the reply T 
(called a positive reply) and proceed as q if the processing of a leads to the reply 
F (called a negative reply). 
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Table 1 Axioms for guarded recursion 

{X\E) = {tx\E) \\X = tx G E RDP 
E ^ X = {X\E) if X G V[E) RSP 



Table 2 Approximation induction principle 

An>0^i(") = T^niv) ^ U = V AIP 



Each closed term of sort T from the language of BTA denotes a finite thread, 
i.e. a thread of which the length of the sequences of actions that it can perform is 
bounded. Guarded recursive specifications give rise to infinite threads. 

A guarded recursive specification over BTA is a set of recursion equations 
E = {X = tx \ X ^ V}, where 1/ is a set of variables of sort T and each tx 
is a term of sort T that has the form D, S or t < a > t'. We write V(i?) for the set 
of all variables that occur on the left-hand side of an equation in E. We are only 
interested in models of BTA in which guarded recursive specifications have unique 
solutions, such as the projective limit model of BTA presented in |4|. 

We extend BTA with guarded recursion by adding constants for solutions of 
guarded recursive specifications and axioms concerning these additional constants. 
For each guarded recursive specification E and each X G V(£'), we add a constant 
of sort T standing for the unique solution of E for X to the constants of BTA. 
The constant standing for the unique solution of E for X is denoted by {X\E). 
Moreover, we add the axioms for guarded recursion given in Table [T] to BTA, 
where we write {tx\E) for tx with, for all Y e V(i?), all occurrences of Y in tx 
replaced by (Y\E). In this table, X, tx and E stand for an arbitrary variable of sort 
T, an arbitrary term of sort T from the language of BTA, and an arbitrary guarded 
recursive specification over BTA, respectively. Side conditions are added to restrict 
the variables, terms and guarded recursive specifications for which X, tx and E 
stand. The equations {X\E) = {tx\E) for a fixed E express that the constants 
{X\E) make up a solution of E. The conditional equations E X = {X\E) 
express that this solution is the only one. 

We will write BTA+REC for BTA extended with the constants for solutions of 
guarded recursive specifications and axioms RDP and RSP. 

In [7 1, we show that the processes considered in BTA+REC can be viewed as 
processes that are definable over AC? lfT4l . 

Closed terms of sort T from the language of BTA+REC that denote the 
same infinite thread cannot always be proved equal by means of the axioms of 
BTA+REC. We introduce the approximation induction principle to remedy this. 
The approximation induction principle, AIP in short, is based on the view that two 
threads are identical if their approximations up to any finite depth are identical. 
The approximation up to depth n of a thread is obtained by cutting it off after 
performing a sequence of actions of length n. 

AIP is the infinitary conditional equation given in Table|2] Here, following ||6l, 
approximation of depth n is phrased in terms of a unary projection operator 7r„. 
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Table 3 Axioms for projection operators 



7ro(w) = D 
7r„+i(S) = S 
7r„+i(D) = D 



P2 



PI 



PO 



TTn+iiu <a>v) = 7r„(u) < a > 7r„(v) P3 



The axioms for the projection operators are given in Table|3] In this table, a stands 
for an arbitrary member of A. 



8.2 Applying Threads to Services 

We extend BTA+REC to a theory that covers the effects of applying threads to 
services. 

It is assumed that there is a fixed but arbitrary set of foci J- and a fixed but 
arbitrary set of methods AA. For the set of basic actions A, we take the set FM — 
{f.m I f E J-,m ^ M}. Each focus plays the role of a name of a service provided 
by the execution environment that can be requested to process a command. Each 
method plays the role of a command proper. Performing a basic action f.m is 
taken as making a request to the service named / to process the command m. 

We introduce a second sort: the sort S of services. However, we will not in- 
troduce constants and operators to build terms of this sort. S is a parameter of 
theories with thread-to-service application. S is considered to stand for the set 
of all services. It is assumed that each service can be represented by a function 
H : M+ {T, F, D} with the property that H{j) = D ^ H{'-f ^ (m)) = D for 
all 7 e Ai^ and m E A4. This function is called the reply function of the service. 
Given a reply function H and a method m E Ai, the derived reply function of H 
after processing m, written -^H, is defined by ^^^(7) = H{{m) ^ 7). 

The connection between a reply function H and the service represented by it 
can be understood as follows: 

- if H{{m)) — T, the request to process command m is accepted by the service, 
the reply is positive and the service proceeds as -^H; 

- if H{{m)) — F, the request to process command m is accepted by the service, 
the reply is negative and the service proceeds as -^H\ 

- if H{{m)) — D, either the processing of command m by the service does not 
halt or the processing of a previous command by the service did not halt. 

Henceforth, we will identify a reply function with the service represented by it. 

It is assumed that there is an undefined service | with the property that f (7) — 
D for all 7 e M+. 

For each / G JF, we introduce the binary apply operator _»/_:TxS^T. 
Intuitively, p»fH is the service that evolves from H on processing all basic actions 
performed by thread p that are of the form f.m by H. When a basic action f.m 
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S.fH 



T 



TSAO 



H 



TSAl 



(it < g.m >v)»fH — 1 



TSA2 



{u<f.m>v) •fH^u.f 

{u < f.m >v)»fH = Vf -^H 

{u<f.m\>v)»fH = \ 



T TSA4 



F TSA5 



D TSA6 



TSA3 



(An>0 ^"(") •/ H ^ U»f H 



T 



TSA7 



performed by thread p is processed by H, p proceeds on the basis of the reply 
value produced. 

The axioms for the apply operators are given in Table |4] In this table, / and g 
stand for arbitrary foci from T and m stands for an arbitrary method from Ai . The 
axioms show that p'f H does not equal t only if thread p performs no other basic 
actions than ones of the form f.m and eventually terminates successfully. 

Let p be a closed term of sort T from the language of BTA+REC and be a 
closed term of sort S. Then p converges from H on f if there exists an n G N such 
that -Knip) * f H ^ f. Notice that axiom TSA7 can be read as follows: if u does 
not converge from H on /, then u»f H equals |. 

The extension of BTA introduced above originates from Q . In the remainder 
of this paper, we will use just one focus. We have introduced the general case here 
because the use of several foci might be needed on further elaboration of the work 
presented in this paper. 

9 The Execution Architecture Services 

In order to be able to use the extension of BTA presented above to describe pro- 
cesses that operate upon the execution architecture for code controlled machine 
structures outlined in Section |2l we have to associate a service with each state of 
the execution architecture. In this section, we first formalize the execution archi- 
tecture for code controlled machine structures and then associate a service with 
each of its states. 



9.1 The Execution Architecture Formalized 

The execution architecture for code controlled machine structures consists of an 
instruction set, a state set, an effect function, and a yield function. The effect and 
yield functions give, for each instruction u and state s, the state and reply, respec- 
tively, that result from processing u in state s. 
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Table 5 Effect function for an execution architecture (i G /) 

eff{set:f:bs,{a,x)) = {a®[f ^ bs],x) 
e.ff{<-m:f, {a, x)) = (a <3 {/}, x) 

e#(cp:/i:/2,(<7,x)) = (o-ffi [/a H^a(/i)],2;) if /i G dom(o-) 

eif (cp:/i;/2, ((J, x)) = {a,x) if /i ^ dom((j) 

e#(mv:/i;/2, (a,x)) = ((a © [/a a{fi)]) <g {/i},x) if /i G dom(o-) 

eif (mv:/i:/2, (cr,^)) = (ct, x) if /i ^ doni(o-) 

e#(cat:/i:/2, (a, a;)) = ((7 [/a ^(/a) ^ a{fi)],x) if /i G dorn(o-) A /a G doin(a) 

eif(cat:/i:/a, (o-,a;)) = ((T,a;) if /i dom(cr) V/a doin((T) 

eif (tsteq:/i:/a, (a, a;)) = ((T,a;) 

eif (tstne:/i:/a, (a, a;)) = ((T,a;) 

eif (tstex:/, (cr,a;)) = (cr, 

e#(load:/, (a, a;)) = (a, a(i)) if / G dom(<T) A a(i) G E 

e#(load:/, (a, a;)) = {a, x) if / ^ dom(a) V a{f) ^ E 

eff{exec:fi: . . . ■ ■ ■ -fL (cr, a^)) = ((... (a © aj) ... o'„),x) 

where a- = [f/ a; cr(/i), . . . , o-(i™)] if a; o-(/i), . . . , a(i™,) G 55 
f7^ = [] if a;..?i„a(/i),...,a(i„) = M 

if a: G -B A /i G dom(o-) A . . . A f™, G dom(CT) A a; o-(/i), . . . , (T(i™,) G 5S 
eff{exec:fi: . . . :im>ii': . . . -f^, ((J, a::)) = {a, x) 

\\xiE\J hi dom(o-) V . . . Vi™, ^ dom(a) V x (7(/i), . . . ,a(i™^) = IVI 
eff{exec:fi: . . . -.fmyfl- ■ ■ ■ -fn, (cr, x)) = sd 

if a; ^ S V/i ^ dom(cr) V . . . V U ^ dom(a) V x ••^j, cr(/i), . . . ,a(i™) = D 
eff{i, So) = sd 



It is assumed that sd (UFeT'fi„(^m)(-^ ^)) x {BS U {M}). Here, Sq 
stands for a state of divergence. 

Let Tl — {BS, {^n I n G N}, E) be a code controlled machine structure. 
Then the execution architecture for 9Jl consists of 

- the instruction set / defined in Section |7j 

- the state set S defined by 




- the effect function eff : I x S ^ S defined in Table [S] 

- the yield function yld ;/xS'— »{T,F,D} defined in Table |6] 

We use the following notation for functions: [ ] for the empty function; [d i-^ r] for 
the function / with dom(/) = {d} such that f{d) — r; f ® g for the function h 
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Table 6 Yield function for an execution architecture (i € /) 



yld{set:f:bs, (cr, a;)) = T 
yld{rm:f, {a,x)) = T 
yld{rm:f, {a,x)) = F 



/ € dom(cr) 
/ ^ dom(fT) 



?/Zrf(cp:/i:/2, (cr,a;)) = T 1 


/i G dom(fr) 






77/ P P I \\ ^ ! 

2/?(i(cp:/i :/2, (cr,x-)) = F 1 


/i ^ dom(fr) 






2/?(i(mv:/i:/2, (cr,a;)) = T i 


/i G dom(cr) 






2/;d(mv:/i:/2, (cr,a;)) = F i 


/i ^ dom(a-) 






2//c;(cat:/i:/2, (cT,a;)) = T i1 


/i e dom(cr) A /2 £ dom(cr) 






2//c;(cat:/i:/2, (cT,a;)) = F i1 


/i ^ dom((r) V /2 dom(a-) 






yld{tsteci:fi:f2, {c7,x)) = T i 


/i e dom(cr) A/2 G dom(cr) A cr(/i) 






?/M(tsteq:/i:/2, {cr,x)) = F i 


/i dom(cr) V/2 dom(cr) V cr(/i) 






?/M(tstne:/i:/2, (a, x)) = T i 


/i G dom(cr) A /2 G dom(CT) A a(/i) 






2/M(tstne:/i:/2, (cr, x)) = F i 


/i dom(cr) V/2 ^ dom(a) V a(/i) 




<^(/2) 


yld{tstex:f , (cr, a:)) = T i 


/ G dom(cr) 






2//c;(tstex:/, (cr,a;)) = F i1 


/ ^ dom(cT) 






yld{\oad:f,((T,x)) = T i1 


/ G dom(cT) A a(f) G £ 






yld{\oad:f , (cr, a;)) = F i 


/ ^ dom(a) V o-(/) ^ E 






2/W(exec:/i: . . . :/„>//: . . . 


,(a,a;)) =T 







if a; G -B A /i G dom(cr) A . . . A /m G dom(o-) A a; ••^ cr(/i), . . . , a{fm,) £ 
yld{exec:fi: . . . ■.fm>fi. . . . if^, {a,x)) = f 

\fx ^ EV fi ^ dom(cr) V ...W fm ^ dom(o-) V x ••gjt o-(/i), . . . , (T{fm) = M 
yld{exec:fi: . . . ■.fm>fi- ■ ■ ■ -fn, {cr, x)) = D 

ifx^EV/i ^dom(cT) V...V/^ ^ dom(o-) V X ..^ (T{h), . . . ,cr{fm) = D 
yld{i,st,) = D 



with Aoui(h) = doin(/) U dom((?) such that for all d G dom(/i), h{d) = f{d) 
if d ^ dom{g) and h{d) = g{d) otherwise; and f < D for the function g with 
dom(£f) = dom(/) \ D such that for all G dom(£f), g{d) = f{d). 

Let (cr, x) G S', and let / G JzN'm. Then / is in use if / G dom((T), and there 
is a loaded executable code if x 7^ M. If / is in use, then (j(/) is the bit sequence 
assigned to / . If there is a loaded executable code, then x is the loaded executable 
code. 

Execute instructions can diverge. When an instruction diverges, a situation 
arises in which no reply can be produced and no further instructions can be pro- 
cessed. This is modelled by eff producing sd and yld producing D. 
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9.2 The Family of Execution Architecture Services 

Each state of the execution architecture for code controlled machine structures can 
be looked upon as a service by assuming that / C and extending the functions 
eff and yld from / to by stipulating that eff{m, s) = Sd and yld{m, s) = D 
for allm € M\I and s G S. 

We define, for each s G S, a cumulative effect function ceff^ : M* ^ 6" in 
terms of s and eff as foUows: 

ceffsil'^im)) = eff{m, ceff^{j)) . 

We define, for each s G 5, an execution architecture service Hg-.Ai^ {T, F, D} 
in terms of ceff^ and yld as follows: 

H,{j ^ (m)) = yld{m, ceff^{j)) . 

For each s E S, Hg is a service indeed: Hs{'y) = D =^ -f^s(7 ^ (™)) = D 
for all 7 £ and m G M. This follows from the following property of the 
execution architecture for code controlled machine structures: 

3s eS. Vie I. 

{yld{i, s) = D A Vs' G 5* . {yld{i, s') - D ^ eff{i, s') = s)) . 

The witnessing state of this property is sq. This state is connected with the unde- 
fined service t as follows: Hs^ — T- 

It is worth mentioning that Hs{{m)) = yld{m, s) and -^Hg = -ffej[f(m,s)- 

We write £4S™ for the family of services {Hg \ s G S}. 

10 Control Codes and Execution Architecture Services 

In this section, we make precise what it means that a control code is installed on 
an execution architecture service and what it means that a control code is portable 
from one execution architecture service to another execution architecture service. 



70.7 Installed Control Codes 

The intuition is that a control code is installed on an execution architecture service 
if either some file name has assigned an executable version of the control code or 
some file name has assigned an interpretable version of the control code and an 
appropriate interpreter is also installed on the execution architecture service. 

Let 9Jt = {BS, I n G N}, E) be a code controlled machine structure, 
let {CCN, ip) be a control code notation for Tt, let c G CCN, and let EAS = 
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-ff(cr,x) € SJS^. Then c is installed on £^^45" if there exist fo,. ■ . ,fi S .TiA/'m with 
a-(/o) e E such that 

V(6si,...,6s^) esr. 

A„eNV'(c) ••to . . . , 6Sm = £7(/o) . . . ,o-(/;), &Sl, . . . , 6Sm • 

A control code is pre-installed on an execution architecture service if the ex- 
ecution architecture service can be expanded to one on which it is installed, us- 
ing only control codes and data already assigned to file names. Thread algebra 
is brought into play to make precise what it means that an execution architecture 
service can be expanded to another execution architecture service. 

Let Wl = {BS, {^n I " £ N}, E) be a code controlled machine structure, 
let EAS = H^^^^) e EM'^, and let EAS' = e SJS'^. Then EAS is 

expansible to EAS' if: 

- dom(f7) C dom(cr') andcr(/) = a'{f) for all / G dom(o-); 

- there exists a thread p without basic actions of the form ea.set:/:6s such that 

EAS' = p .ea EAS. 

Let 9Jt = {BS, {/x„ I n € N}, £■) be a code controlled machine structure, let 
( CCN, tp) be a control code notation for m, let c G CCN, and let EAS e £JS™. 
Then c is pre-installed on EAS if 

- c is not installed on EAS; 

- there exists a EAS' G £JS^ such that EAS is expansible to EAS' and c is 
installed on EAS' . 

Examples Take an assembly code notation AGN and a source code notation 
SCN. Consider an execution architecture service EAS on which file name /i has 
assigned an executable version of an assembler for A CN , file name /2 has assigned 
an ACN version of a compiler for SCN, and file name /a has nothing assigned. 
Suppose that no file name has assigned an executable version of the compiler. 
Then the compiler is not installed on EAS. However, the compiler is pre-installed 
on EAS because it is installed on the expanded execution architecture service 
(ea.load:/i o ea.exec:/2>/3) "ea EAS. 

10.2 Portable Control Codes 

We take portabihty of control code to mean portabihty from a service defined by 
the execution architecture for one machine structure to a service defined by the 
execution architecture for another machine structure. 

Transportability is considered a property of all bit sequences, i.e. each bit se- 
quence can be transported between any two services defined by execution archi- 
tectures for machine structures. Therefore, it is assumed that every bit sequence 
assigned to a file name on a service can be assigned to a file name on another 
service by means of an instruction of the form set:/: 6s. 
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A prerequisite for portability of a control code from a service defined by the 

execution architecture for one machine structure to a service defined by the execu- 
tion architecture for another machine structure is that, for all inputs covered by the 
former machine structure, the outputs produced under control of the control code 
coincide for the two machine structures concerned. Moreover, it must be possible 
to expand the service from which the control code originates such that the control 
code is pre-instaUed on the other service after some bit sequences assigned to file 
names on the expanded service are assigned to file names on the other service. 

Let m = {BS,{nn I n G N},^;) and SOI' = (-B5", {/x^ | n G n},E') 
be code controlled machine structures such that BS C BS', let {CCN, tp) and 
{CCN, tjj') be control code notations for dJl and 971', respectively, let c G CCN, 
and let EASq = ^^(ao.cco) ^ and EAS'q = -ff(<^/,^/) G SJS'^' . Then c is 

portable from EASq to EAS'q if 

- V(&si, . . . , hsjn) G BS* • 

{i}{c) ••l]^ bsi,..., bsm ^ D 
^ A„eNV'(c) ••m ^■si' ■■■,bsm = ilj'ic) bsi,...,bsm) ■ 

- there exists a EASi = -ff(cri,xi) G ^iAS^^ such that 

- EASo is expansible to EASi, 

- there exist /i, . . . G dom((Ji) \ dom((TQ) such that c is pre-instaUed on 
(ea.set:/i:cri(/i) o . . . o ea.set://:(Ti(/;)) •ea EAS'„. 

Because we assume that the set J^m of file names is countably infinite, this 
definition does not imply that the bit sequences to be transported have to be as- 
signed to the same file names at both sides. 

Example 4 Take a source code notation SCN and an assembly code notation 
ACN. Consider an execution architecture service EAS on which file name /i 
has assigned an executable version of a compiler for SCN that produces as- 
sembly codes from ACN, file name J2 has assigned a source code from SCN, 
and file name /s has nothing assigned. Moreover, consider another execution ar- 
chitecture service EAS' on which file name /i has assigned an executable ver- 
sion of an assembler for ACN, and file name /a has nothing assigned. Suppose 
that the above-mentioned prerequisite for portabihty of the source code is ful- 
filled. Then the source code is portable from EAS to EAS' because it is pre- 
installed on ea.set:/3:6s "ea EAS' where 6s is the bit sequence assigned to /s on 
(ea.load:/i o ea. exec 1/2 >/3) "ea EAS. 

11 Conclusions 

We have presented a logical approach to explain issues concerning control codes 
that are independent of the details of the behaviours that are controlled at a very ab- 
stract level. We have illustrated the approach by means of examples which demon- 
strate that there are non-trivial issues that can be explained at this level. In the 
explanations given, we have consciously been guided by empirical viewpoints usu- 
ally taken by practitioners rather than theoretical viewpoints. The issues that have 
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been considered are well understood for quite a time. Application of the approach 
to issues that are not yet well understood is left for future work. We think among 
other things of applications in the areas of software asset sourcing, which is an 
important part of IT sourcing, and software patents. At least the concept of control 
code can be exploited to put an end to the lack of conceptual clarity in these areas 
about what is software. 

We have based the approach on abstract machine models, called machine struc- 
tures. If systems that provide execution environments for the executable codes of 
machine structures are involved in the issues to be explained, then more is needed. 
We have introduced an execution architecture for machine structures as a model of 
such systems and have explained portability of control codes using this execution 
architecture and an extension of basic thread algebra. The execution architecture 
for machine structures, as well as the extension of basic thread algebra, may form 
part of a setting in which the different kinds of processes that are often trans- 
ferred when sourcing software assets, in particular software exploitation, can be 
described and discussed. 

We have looked at viewpoints of practitioners from a theoretical perspective. 
Unfortunately, it is unavoidable that the concepts introduced cannot all be asso- 
ciated directly with the practice that we are concerned about. This means that 
reading of the paper might be difficult for practitioners. Therefore, the paper must 
be considered a paper for theorists. 

We have explained issues originating from the areas of compilers and software 
portability. The literature on compilers is mainly concerned with theory and tech- 
niques of compiler construction. A lot of that has been brought together in text- 
books such as lfTl l26ll . To our knowledge, the phenomenon that we call the com- 
piler fixed point is not even informally discussed in the literature on compilers. 
The literature on software portability is mainly concerned with tools, techniques 
and guidelines to achieve portability. The best-known papers on software porta- 
bility are early papers such as |22 ,23|. To our knowledge, the concept of portable 
program is only very informally discussed in the literature on software portability. 
Moreover, we are not aware of formal descriptions of compiler fixed point and 
portable program in the literature on formal methods. 
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